Before a new drug may be sold in many countries of the world, regulatory approval must be granted. One of the most expensive and difficult aspects of obtaining this regulatory approval is the presentation of statistically significant data from clinical trials. Typically, clinical trials used to support a new drug application are divided into three or more phases, the most prominent of which are phases I, II, and III.
Phase I studies are primarily concerned with assessing the safety of a drug. Phase I testing in humans is typically done in about 20 to 100 healthy volunteers. A phase I clinical study is designed to determine what happens to the drug in the patient. That is, how it is absorbed, metabolized, and excreted. In addition, by measuring the side effects of the drug at various dosage levels, a phase I study provides information on optimal drug dosage.
While a phase I study is directed to drug safety, a phase II clinical trial is directed to drug efficacy. A phase II study occurs after successful completion of a phase I study. A phase II clinical study may last from several months to two years, and involve up to several hundred patients at numerous clinical sites throughout the world. Most phase II studies are randomized trials. One group of patients receives the experimental drug while a control group receives a placebo. Often phase II studies are “blinded” in the sense that neither the patients nor the researchers know who is getting the experimental drug. In this manner, the phase II study can provide a pharmaceutical company and a regulatory body, such as the United States Food and Drug Administration (FDA) of the United States or the European Commission (EC) of the European Union, comparative information about the efficacy of the new drug. If the phase II study is successful, a phase III study may be authorized.
Typically, in a phase III study, the new drug is tested in several hundred to several thousand patients at hundreds of clinical sites throughout the world. This large-scale testing provides the pharmaceutical company and the regulatory agency with a more thorough understanding of the drug's effectiveness, benefits, and the range of possible adverse reactions. Most phase III studies are randomized and blinded trials. Phase III studies typically last several years. Once a phase III study is successfully completed, a pharmaceutical company can request regulatory approval for marketing the new drug.
The resources needed to support a complex multi-site phase II or phase III clinical are staggering. Trained professionals must administer the new drug under the exact requirements of the protocols of the clinical study and intricate patient records must be maintained. The clinical trial protocol may require numerous patient visits over an extended period of time. Any error in the patient record could result in patient data disqualification.
Because of the complexity of the protocols used in clinical trials, the amount of information that must be tracked requires the capabilities of a back-end clinical data management system (CDMS). Representative back-end clinical data management systems include Clintrial 4.3, (Clinsoft Corporation, Lexington, Mass., www.clinsoft.net), and Oracle Clinical (O/C), Oracle Inc., Redwood Shores, Calif., www.oracle.com). These back-end clinical data management systems typically provide sophisticated tools such as, a batch validation engine, a batch data loader, a randomization system, a thesaurus management system, and a lab reference range system. However, because a clinical trial may be conducted at hundreds of sites throughout the world, it is impracticable to place a back-end CDMS at each clinical site. The problem of routing clinical data into a back-end CDMS: has therefore been addressed by a number of different approaches in the art.
A traditional approach to routing clinical data to a back-end CDMS is to gather clinical data at each site using paper-based forms designed in accordance with the specifications of a clinical trial. At a later date, the paper-based forms are manually entered twice into a computer. This double-entry is requested in order to compare the two data sets in order to check for data entry errors. While this approach is functional, it is unsatisfactory. Electronic data entry based on the paper-based forms is often done at a site that is remote from the clinical setting, making it difficult to consult the clinician if there is a problem with the content of the paper-based forms. Because of the exact requirements of the clinical trial protocol, such unresolved errors typically result in patient disqualification. Another problem with paper-based forms is that the information is essentially processed twice, first, when the data is entered on the paper-based form and, second, when the electronic data entry is done based on the content of the paper-base forms. This effectively doubles the chance of error in the data entry process. Yet another problem with paper based forms is that there is considerable delay before the clinical data is available is review because a sponsor needs to wait until the clinical data is entered into the back-end database before electronic analysis may be run on the clinical data.
To address the problems with traditional approaches to clinical data entry into a legacy CDMS, an entire industry of Remote Data Entry (RDE) products has developed. Representative vendors in this industry include InferMed, Ltd., London UK, (www.infermed.com), Phase Forward Inc., Waltham, Mass., (www.phaseforward.com), CB Technology, Philadelphia, Pa., (www.cbtech.com), DataTRAK Cleveland, Ohio, (www.datatraknet.com), and Araccel, Stockholm, Sweden, (www.araccel.com), and TEAMworks, Hannover, Germany (www.teamworks.de). These RDE products are also termed front-end data acquisition products. RDE products provide capabilities for making electronic clinical data entry forms that are used on a client computer, such as a laptop, at the clinical site. Data collected using an RDE product are sent electronically to a centralized back-end CDMS where statistical analysis is performed on the clinical data to ascertain drug efficacy and/or safety.
RDE products are advantageous because they prevent discrepancies during data entry. An RDE product provides electronic case report forms (eCRFs) to the data entrant for entry of clinical data. The eCRF is capable of containing data validation checks that show a warning in the case when incorrect or “out of the programmed range” entries are received. The data entrant can then correct the problem with the data entry immediately. In addition the eCRF provides “protocol guidance.” For example, pregnancy test questions are only displayed to the data entrant when the patient has indicated that she is female.
While RDE products represent an advance over the paper-based form approach, they are unsatisfactory. RDE products require a custom study definition to be prepared for each clinical trial. For example, MACRO from InferMed, Ltd., London UK, requires that a macro study definition be prepared for each clinical trial monitored by MACRO. The macro study definition is a collection of metatables that describe the patient data collected at a clinical site. The macro study definition may also include the format of the electronic forms used to acquire the clinical data as well as other pertinent data acquisition components.
In the art, a clinical definition must be set up for the back-end CDMS. The back-end clinical definition is a data structure that is used to track all the patients in a clinical study. The back-end clinical definition is designed in accordance with the specifications of the particular back-end CDMS used to support a particular clinical study. The problem with the RDE custom study definitions and the back-end clinical definitions becomes apparent when one tries to interface the RDE custom study definition to the back-end clinical definition. Because there are no industry standards for RDE study definitions and back-end clinical definitions, significant custom programming is needed for each clinical study, in order to allow an RDE system to electronically feed data to a back-end CDMS.
A third approach to addressing the problem of clinical data entry is to provide a web page interface to a back-end CDMS. An example of a product that uses this approach is Oracle Clinical Remote Data Capture v4i, Oracle Inc., Redwood Shores, Calif. In this approach, each clinical site includes a client computer with a standard web browser. The web browser is used to load into the client computer a data entry form from a remote web server. Clinical data are then entered into the data entry form. Advantageously, the data entered into the web-based data entry form may be electronically entered directly into the back-end CDMS. While the third approach eliminates the need to interface a front-end study definition with a back-end clinical definition, this approach is still unsatisfactory. First, the client computer must be connected to the back-end CDMS by a long-distance network throughout data entry. This requirement limits how the web page interface may be constructed and deployed. Another disadvantage to using a long-distance network throughout data entry are the issues of network latency, network bandwidth limitations, and server load that are inevitably raised. These issues conspire to make data entry a frustrating experience. In fact, it is widely appreciated that data entry using a web page driven by a remote server requires tremendous patience. For example, consider the amount of patience required to enter personal data at an Internet web site, such as www.amazon.com, in order to register at the site. Clinical data entry using a web page system, such as Oracle Clinical Remote Data Capture v4i, is comparable to registering hundreds to thousands of people at a site such as www.amazaon.com or www.gap.com on a periodic basis over an extended period of time.
Yet another disadvantage of using a web page interface to a back-end CDMS is that back-end CDMS interfaces are designed for data-entry clerks. Therefore, they lack support for the tools necessary to ensure that clinical trial protocol is followed. Such tools include protocol violation alerts, enforced eligibility, and protocol recommendations regarding dosing or test procedures. Furthermore, direct data entry into a back-end CDMS using a web-page introduces questionable practices. Back-end CDMS interfaces are designed to facilitate data entry by data-entry clerks. As such, many of the fields in the data entry forms have defaulted answers. While the use of defaulted answers is appropriate for routine data-entry, it is not appropriate for forms that are considered source documents. A source document represents the form that records actual clinical observations. In order to ensure that all clinical observations mandated by a clinical protocol are actually made, the source form should not have defaulted answers.
In view of these difficulties, what is needed in the art is a system and method for collecting clinical data without the many drawbacks found in preexisting systems and methods.
Discussion or citation of a reference herein will not be construed as an admission that such reference is prior art to the present invention.